IBIS Macromodel Task Group

Meeting date: 07 May 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:       Ambrish Varma
                              Ken Willis
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                              Stephen Slater
                              Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 30
meeting.  Arpad noted two corrections himself.  The line below the attendees
list showed Curtis as the author of the minutes, but Mike L. had taken the
minutes.  The second to last sentence in the second to last paragraph was
incomplete.  Mike corrected it to:
 "Ambrish still felt that the threshold should be a factor."
Mike made both changes to the archived copy of the minutes.  Walter moved to
approve the minutes with the changes.  Michael M. seconded.

-------------
New Discussion:

Jitter Amplification:
Michael Mirmak asked if we need to update the reserved jitter parameters in the
spec, particularly the Tx parameters, to separate the high and low frequency
components of the jitter.  He noted a DesignCon paper from 2014 and several IEEE
papers had explored 'jitter amplification' by the channel.  He noted that we
know "low" frequency jitter is not amplified by the channel but "high" frequency
jitter may be.  He said the tool might want to account for the two ranges
differently.

Michael M. asked if we should define a parameter for a cutoff frequency.  Mike
L. asked if this binary approach would be oversimplifying what is a continuous
variation.  Michael M. said he was hoping to start with a simple proposal and
avoid the complications of a table based solution.

Walter suggested that we might introduce something like jitter_spectral_density
and have a short table.  He noted that people generally don't like tables, but
said this might be the simplest way to resolve the issue.  It would avoid any
vagaries in defining what "low" and "high" are.

Michael M. asked if a table describing the spectral density was sufficient.
Fangyi said you need the existing parameters, like Tx_Rj and Tx_Dj, to define
the distribution of the amplitudes, and you would add corresponding tables to
define the spectral density.  He noted that the units of the existing parameters
were s and the units of the new spectral density tables would be s^2/Hz.

Michael M. said that answered his question, and a BIRD would have to be written.
This would give the model maker a way to split up the jitter components in a way
that allowed tools to process the system effects correctly.

BIRD197.3_draft_3.3 (DC_Offset):

Arpad noted that the previous week's discussion on the InOut nature of DC_Offset
had led to questions about whether the value returned by the model should be
called a "threshold" instead of an "offset".  He noted that with current AMI
usage for SERDES, the waveforms were always difference waveforms, and the
Rx_Receiver_Sensitivity specifies the magnitude of the deviation from 0V in the
difference waveform necessary to record a high or low.  This would have to be
revisited, and any relationships between threshold and sensitivity would need to
be defined.

Fangyi reviewed some thoughts from an email he had sent to ATM replying to
Arpad's questions:
  - DC_Offset does not need to be tied to the threshold; they can be different.
  - The input signal can have a DC_Offset, and then the threshold is something
    for deciding high/low and they're conceptually different.  Arpad agreed.
  - As Ambrish had noted the previous week, the waveform returned by Rx
    GetWave() is prior to the decision process in the core logic.  So, we don't
    need to tie any DC offset to the threshold.
  - If the model wants to provide threshold information to the EDA tool, we have
    a way in the spec right now for PAM4 (PAM4_UpperThreshold, etc.).  We could
    add an analogous single threshold value for NRZ.
  - Rx_Receiver_Sensitivity is not tied to a fixed threshold.  When you measure
    a BER you first come up with a threshold, and once that's chosen you can
    find the value of Rx_Receiver_Sensitivity.  So, the relationship between the
    waveform and Rx_Receiver_Sensitivity is not really DC_Offset.

Arpad asked how we incorporate this information and decide whether DC_Offset
should be InOut or go back to being In only.  Fangyi said we can let the model
decide what to do, because its GetWave() is free to return a model that is
zero-centered or not zero-centered.  The problem in this case is what to do for
a statistical simulation.  How would the model specify the DC component of the
output waveform for a statistical simulation?  We could introduce a
DC_For_Statistical.  Arpad noted for clarity that previous discussions
had been focused on keeping the waveform returned by Rx GetWave() zero-centered,
but Fangyi was now suggesting the returned waveform need not be zero-centered.
Fangyi agreed.  Arpad asked if anyone disagreed with this statement.  No one
objected.

Walter noted that he agreed with Fangyi, but said if the model wanted a certain
threshold to be used it could simply subtract that value from the waveform
before returning it.  Fangyi agreed, and said the model was free to do that or
we could add an NRZ equivalent of the PAM4 threshold parameters.

Walter noted a practical example of the usage of a new DC_For_Statistical
parameter.  Coming into a DDR5 Rx, the DC offset might be .7V.  What you're
supposed to do is set the VrefDQ register so it subtracts .7V from the signal,
but that register provides discrete steps (e.g. 5mV increments), so you're
always a couple mV off from being centered at zero.  One way to handle that
uncertainty is for the tool to build 5mV of margin into the eye masks.  Another
would be to have the model return the offset value in this new parameter.

Fangyi noted that in his email response he had suggested we could make DC_Offset
an In and add the new DC_For_Statistical, which would be an Out.

Arpad noted that he had discussed the topic with Vladimir.  Vladimir had asked
about DC gain in the Tx or Rx equalizer.  Fangyi noted that we had previously
decided there was no issue with DC gain in the Tx.  For the Rx, Fangyi noted
that this DC gain could be included in the DC_For_Statistical value, as noted
above in Walter's example.  For the GetWave() based simulation, the model can
return whatever it wants in the waveform itself.

Arpad asked if DC_For_Statistical should be defined in a separate BIRD or added
to this DC_Offset BIRD.  Fangyi thought it should be added to the same BIRD.
Fangyi took the AR to modify Ambrish's latest draft and add the new parameter.

- Curtis: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.

AR: Fangyi to create a BIRD197.3 draft 4 to incorporate his DC_For_Statistical
parameter.

-------------
Next meeting: 14 May 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
